Non-intrusive proximity based advertising and message delivery

ABSTRACT

Provided are techniques for controlling message delivery corresponding to a near field communication (NFC) device, comprising establishing, on a mobile computing device, a rule-based session corresponding to a NFC device; executing an application, corresponding to the NFC device, in conjunction with the session; and responsive to detecting a condition meeting a criterion corresponding to the rule-based session, limiting execution of the application on the mobile computing device in conformity with the criterion.

FIELD OF DISCLOSURE

The claimed subject matter relates generally to Near Field Communication(NFC) devices typically referred to a “beacons” and, more specifically,to techniques for the management of beacon-related applications.

BACKGROUND OF THE INVENTION

A new technology currently being introduced throughout the world is NearField Communication (NFC) devices typically referred to as a “beacons.”A beacon typically employs Bluetooth low energy (BLE) to transmit asimple message to suitably configured mobile devices such as, but notlimited to, a smart telephone. The message transmitted may be auniversally unique identifier (UUI) such as an Internet Protocol (IP)address. Once a mobile device receives the UUI, the telephone mayexecute an application that uses the beacon to establish the location ofthe telephone relative to the beacon and receive notificationscorresponding to the beacon. It the application is not already loaded onthe mobile device, the application is typically downloaded from a remotesource.

SUMMARY

The claimed subject matter relates generally to Near Field Communication(NFC) devices typically referred to a “beacons” and, more specifically,to techniques for the management of beacon-related applications by theestablishment, on a mobile computing device, of a “session” that maymanage one or more applications

Provided are techniques for controlling message delivery correspondingto a near field communication (NFC) device, such as a beacon. Thetechniques include establishing, on a mobile computing device, arule-based session corresponding to a NFC device; executing anapplication, corresponding to the NFC device, in conjunction with thesession; and responsive to detecting a condition meeting a criterioncorresponding to the rule-based session, limiting execution of theapplication on the mobile computing device in conformity with thecriterion.

This summary is not intended as a comprehensive description of theclaimed subject matter but, rather, is intended to provide a briefoverview of some of the functionality associated therewith. Othersystems, methods, functionality, features and advantages of the claimedsubject matter will be or will become apparent to one with skill in theart upon examination of the following figures and detailed description.

BRIEF DESCRIPTION OF THE DRAWINGS

A better understanding of the claimed subject matter can be obtainedwhen the following, detailed description of the disclosed embodiments isconsidered in conjunction with the following figures.

FIG. 1 is a block diagram of a Beacon Management architecture (BMA)configured in accordance with an embodiment of the claimed subjectmatter.

FIG. 2 is a block diagram of a smartphone, first introduced in FIG. 1,in greater detail.

FIG. 3 is a block diagram of a Beacon Management Module (BMM), firstintroduced in FIG. 2, in greater detail.

FIG. 4 is a flowchart of one example of an Initiate Session process thatmay implement aspects of the claimed subject matter.

FIG. 5 is a flowchart of one example of a Monitor Beacons process thatmay implement aspects of the claimed subject matter.

FIG. 6 is an illustration of a smartphone screen shot generated inaccordance with the claimed subject matter.

FIG. 7 is an illustration of a second smartphone screen shot generatedin accordance with the claimed subject matter.

FIG. 8 is an illustration of a third smartphone screen shot generated inaccordance with the claimed subject matter.

DETAILED DESCRIPTION

The present invention may be a system, a method, and/or a computerprogram product at any possible technical detail level of integration.The computer program product may include a computer readable storagemedium (or media) having computer readable program instructions thereonfor causing a processor to carry out aspects of the present invention.

The computer readable storage medium can be a tangible device that canretain and store instructions for use by an instruction executiondevice. The computer readable storage medium may be, for example, but isnot limited to, an electronic storage device, a magnetic storage device,an optical storage device, an electromagnetic storage device, asemiconductor storage device, or any suitable combination of theforegoing. A non-exhaustive list of more specific examples of thecomputer readable storage medium includes the following: a portablecomputer diskette, a hard disk, a random access memory (RAM), aread-only memory (ROM), an erasable programmable read-only memory (EPROMor Flash memory), a static random access memory (SRAM), a portablecompact disc read-only memory (CD-ROM), a digital versatile disk (DVD),a memory stick, a floppy disk, a mechanically encoded device such aspunch-cards or raised structures in a groove having instructionsrecorded thereon, and any suitable combination of the foregoing. Acomputer readable storage medium, as used herein, is not to be construedas being transitory signals per se, such as radio waves or other freelypropagating electromagnetic waves, electromagnetic waves propagatingthrough a waveguide or other transmission media (e.g., light pulsespassing through as fiber-optic cable), or electrical signals transmittedthrough a wire.

Computer readable program instructions described herein can bedownloaded to respective computing/processing devices from a computerreadable storage medium or to an external computer or external storagedevice via as network, for example, the Internet, as local area network,a wide area network and/or a wireless network. The network may comprisecopper transmission cables, optical transmission fibers, wirelesstransmission, routers, firewalls, switches, gateway computers and/oredge servers. A network adapter card or network interface in eachcomputing/processing device receives computer readable programinstructions from the network and forwards the computer readable programinstructions for storage in a computer readable storage medium withinthe respective computing/processing device.

Computer readable program instructions for carrying out operations ofthe present invention may be assembler instructions,instruction-set-architecture (ISA) instructions, machine instructions,machine dependent instructions, microcode, firmware instructions,state-setting data, configuration data for integrated circuitry, oreither source code or object code written in any combination of one ormore programming languages, including an object oriented programminglanguage such as Smalltalk, C++, or the like, and procedural programminglanguages, such as the “C” programming language or similar programminglanguages. The computer readable program instructions may executeentirely on the user's computer, partly on the user's computer, as astand-alone software package, partly on the user's computer and partlyon a remote computer or entirely on the remote computer or server. Inthe latter scenario, the remote computer may be connected to the user'scomputer through any type of network, including a local area network(LAN) or a wide area network (WAN), or the connection may be made to anexternal computer (for example, through the Internet using an InternetService Provider). In some embodiments, electronic circuitry including,for example, programmable logic circuitry, field-programmable gatearrays (FPGA), or programmable logic arrays (PLA) may execute thecomputer readable program instructions by utilizing state intimation ofthe computer readable program instructions to personalize the electroniccircuitry, in order to perform aspects of the present invention.

Aspects of the present invention are described herein with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems), and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer readable program instructions.

These computer readable program instructions may be provided to aprocessor of a general purpose computer, special purpose computer, orother programmable data processing apparatus to produce a machine, suchthat the instructions, which execute via the processor of the computeror other programmable data processing apparatus, create means forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks. These computer readable program instructionsmay also be stored in a computer readable storage medium that can directa computer, a programmable data processing apparatus, and/or otherdevices to function in a particular manner, such that the computerreadable storage medium having instructions stored therein comprises anarticle of manufacture including instructions which implement aspects ofthe function/act specified in the flowchart and/or block diagram blockor blocks.

The computer readable program instructions may also be loaded onto acomputer, other programmable data processing apparatus, or other deviceto cause a series of operational steps to be performed on the computer,other programmable apparatus or other device to produce a computerimplemented process, such that the instructions which execute on thecomputer, other programmable apparatus, or other device implement thefunctions/acts specified in the flowchart and/or block diagram block orblocks.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods, and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof instructions, which comprises one or more executable instructions forimplementing the specified logical function(s). In some alternativeimplementations, the functions noted in the blocks may occur out of theorder noted in the Figures. For example, two blocks shown in successionmay, in fact, be executed substantially concurrently, or the blocks maysometimes be executed in the reverse order, depending upon thefunctionality involved. It will also be noted that each block of theblock diagrams and/or flowchart illustration, and combinations of blocksin the block diagrams and/or flowchart illustration, can be implementedby special purpose hardware-based systems that perform the specifiedfunctions or acts or carry out combinations of special purpose hardwareand computer instructions.

Turning now to the figures, FIG. 1 is a block diagram of one example ofa Beacon Management architecture (BMA) 100 in which the claimed subjectmatter may be implemented. A web server 102 includes a centralprocessing unit (CPU) 104, which would typically include one or moreprocessors (not shown), coupled to a monitor 106, a keyboard 108 and apointing device, or “mouse,” 110, which together facilitate humaninteraction with architecture 100 and web server 102. Also included inweb server 102 and attached to CPU 104 is a non-transitorycomputer-readable storage medium (CRSM) 112, which may either beincorporated into web server 102 i.e. an internal device, or attachedexternally to CPU 104 by means of various, commonly available connectiondevices such as but not limited to, a universal serial bus (USB) port(not shown). CRSM 112 is illustrated storing an example of a beaconserver (BS) 114 that stores information related to beacons managed inaccordance with the claimed subject matter. Typically, informationrelated to particular beacons is stored on a remote computing devicesuch as web server 102 and transmitted to users by a BS 114 in responseto a query related to any particular beacon. For example, a particularbeacon at a retail location may have corresponding information relatedto the description and pricing of a product associated with the beaconstored on BS 114. This information is typically transmitted to a user'smobile device in response to a request to download the information. Theclaimed subject matter enables, among other features, a user to controlwhether or not a request is made and the timing of requests forinformation, thus preventing the user from being presented withextraneous information. It should be noted that a typical architecturemay include many web servers servicing ninny beacons but for the sake ofsimplicity only one beacon server is shown.

Web server 102 and CPU 104 are connected to the Internet 120, which isalso connected to a mobile computing device, or in this example, asmartphone 122. Smartphone 122 includes a display, or “screen,” 124, amicrophone 126 and a camera 128. Although in this example, web server102 and smartphone 122 are illustrated communicatively coupled to theInternet 120, the connection would typically be made via any number ofcommunication mediums such as, but not limited to, a WiFi network (notshown) or a cellular telephone network (not shown). In addition, thefunctionality of the claimed subject matter doesn't necessarily dependupon a connection to the Internet and other connections betweensmartphone 122 and web server 102 are also possible. Further, it shouldbe noted there are many possible configurations for a BMA, of whicharchitecture 100 is only one simple example.

Also illustrated in FIG. 1, is an example of a scenario in which theclaimed subject matter may be employed. A retail business 134 is usedthroughout the Specification to describe some of the functionalityassociated with the disclosed technology. In the example, retailbusiness 134 has two (2) doors. i.e. a door 136 and a door 138, throughwhich a shopper 130 may enter and exit retail business 134. Althoughshopper 130 is illustrated at various positions throughout retailbusiness 134, shopper 130 is only labeled at a beginning position of apath walked that consists of five (5) portions, i.e., a P_1 141, as P_2142, a P_3 143 a P_4 144 and a P_5 145. Throughout and in proximity toretail business 134 are positioned several beacons, i.e., a B_1 151, aB_2 152, a B_3 153, a B_4 154, a B_5 155 and a B_6 156. Shopper 130,paths 141-145 and beacons 151-156 are used throughout the Specificationto describe aspects of the claimed subject matter.

FIG. 2 is a block diagram of smartphone 122, first introduced in FIG. 1,in greater detail. In this example, components of smartphone 122 includea CPU 162, which would include one or more physical processors (notshown), a memory 164, which includes a random access memory (RAM) 166, acache memory 168 and a non-transitory, computer-readable storage medium(CRSM) 172. CRSM 172 is illustrated as storing an operating system (OS)174 and a Beacon Management Module (BMM) 176. BMM 176 is responsible forimplementing aspects of the claimed subject matter and is described inmore detail below in conjunction with FIGS. 3-8.

Also included in smartphone 122 are Input/Output (I/O) interfaces(s) 178and a transmitter/receiver 182. I/O interface(s) 178 enables smartphone122 to interact with display 124 (FIG. 1) and other devices 184 that maybe attached. Examples of other devices include microphone 126 (FIG. 1)and camera 128 (FIG. 1). Transmitter/receiver 182 enables smartphone 122to be communicatively coupled to communication mediums such as, but notlimited to, a cellular telephone network (not shown) and a WiFi network(not shown). Such connections enable smartphone to be communicativelycoupled to other networks and devices such as the Internet 120 (FIG. 1)and web server 102 (FIG. 1). CPU 162, memory 164, I/O interface(s) 178and transmitter/receiver 182 communicate with each other withinsmartphone 122 over a communication bus 186.

It should be understood that FIG. 2 is a simplified illustration of asmartphone or any other device that may implement the claimed subjectmatter. While various components are described to aid in the followingdescription of the disclosed technology, other components, both optionaland necessary for the functionality of smartphone 122 may be omitted forthe sake of simplicity. Further, smartphone 122 is only one singleexample of a device that may be configured in accordance with theclaimed subject matter. Those with skill in the relevant arts shouldappreciate that other types of devices, both actual and yet to bedeveloped, may also benefit from the claimed technology.

FIG. 3 is a block diagram of BMM 176, first introduced in FIG. 2, ingreater detail. In this example, logic associated with BMM 176 is storedon CRSM 172 (FIG. 2) and executes on CPU 162 (FIG. 2) of smartphone 122(FIGS. 1 and 2). It should be understood that the claimed subject mattercan be implemented in many types of devices and data storage structuresbut, for the sake of simplicity, is described only in terms ofsmartphone 122 and architecture 100 (FIG. 1). Further, therepresentation of BMM 176 in FIG. 3 is a logical model. in other words,components of BMM 176 may be hardware or software stored in the same orseparates files and loaded and/or executed within system 100 either as asingle system or as separate processes interacting via any availableinter process communication (IPC) techniques.

BMM 176 includes an input/output (I/O) module 202, a data module 204, anapplication management module (AMM) 206, a session management module(SMM) 208 and a graphical user interface (GUI) 210. I/O module 202handles any communication BMM 176 has with other components ofsmartphone 122 and architecture 100. Data module 204 is a datarepository for information that BMM 176 requires during normaloperation. Examples of the types of information stored in data module204 include user data 212, beacon data 214, session data 216, operatinglogic 218 and operating parameters 220.

User data 212 stores information that specifies preferences that controlthe operation of smartphone 122 that have been set by a user ofsmartphone 122. In the following examples, the user of smartphone 122 isshopper 130 (FIG. 1). Examples of specific elements of user data 212 mayinclude, but are not limited to, parameters that control default timeoutand distance restrictions on beacons. Beacon data 214 stores informationon specific beacons, which in this example are beacons 151-156 (FIG. 1).Such information may include, but is not limited to, the identity,location, UUI of beacons 151-156 as well as any applications that may beassociated with a particular beacon 151-156. Beacon data 214 may alsoindicate an application for a particular beacon has not yet beendownloaded. Session data 216 stores information on any sessions thathave been initiated with respect to beacons 151-156. For example, asshopper 130 walks through retail business 134 (FIG. 1), beacons 151-156are encountered and one or more sessions may be initiated and managed inaccordance with the claimed subject matter. The use of user data 212,beacon data 214 and session data 216 is described in more detail belowin conjunction with FIGS. 4-8.

Operating logic 218 stores executable code for the implementation of theclaimed subject matter on smartphone 122, including the coordination ofcomponents 202, 206, 208 and 210. Operating parameters 220 includesinformation on various user preferences that have been set, includingbut not limited to, the look and feel of notifications and defaultvalues for parameters that may control aspects of the operation of BMM176.

AMM 206 controls the data that is transmitted to and from beacons151-156, typically on an application-by-application basis. It should beunderstood that each of beacons 151-156 would typically be associatedwith an application, with some applications handling multiple beacons.Data from beacons 151-156 is analyzed by AMM 206 to determine suchinformation as whether or not the beacon has been encountered before, ifthere is a corresponding session in beacon data 212 and whether or notto initiate a session associated with a particular beacon. AMM 296 alsodetermines whether or not a particular beacon 151-156 is associated witha specific application and whether the application has been or needs tobe downloaded. SMM 208 receives signals from AMM 206 and, if necessary,initiates a session to manage the data from a particular beacon 151-156.AMM 206 and SMM 208 and their operation are described in more detailbelow in conjunction with FIGS. 4-8. GUI component 210 enables users ofsmartphone 122 and BMM 176 to interact with and to define the desiredfunctionality of BMM 176. Typically, by setting of variables inoperating parameters 220.

FIG. 4 is a flowchart of one example of an Initiate Session process 250that may implement aspects of the claimed subject matter. In thisexample, logic associated with process 259 is stored on CRSM 172 (FIG.2) and executed on one or more processors (not shown) of CPU 162 (FIG.2) and smartphone 122 (FIGS. 1 and 2) in conjunction with BMM 176 (FIGS.2 and 3). The following description uses shopper 130 (FIG. 1) andbeacons 151-156 (FIG. 1) as examples of how the claimed subject matterworks and may be implemented.

Process 250 may be initiated in several different ways, depending upon aparticular user's configuration. For example, process 250 may beinitiated by a different process (not shown) that continually monitorsfor active beacons within range. In another configuration, a user whomdoes not wish to be continually interrupted by beacons may explicitlyinitiate process 250. For example, there might be a sign indicating thepotential to interact with a particular beacon, such as a sign at asubway station that uses beacons to augment route maps, or on a storesign advertising a sale. In these examples, the user might take outtheir phone and initiate a session with a gesture like a shake or swipe,but with the phone not otherwise interacting with beacons.

Process 250 starts in to “Begin Initiate Session” block 252 and proceedsimmediately to a “Detect Beacon” block 254. It should be understood thatblock 254 is only executed once a user has enabled interactions withbeacons. In other words, in the event a user has not yet indicated thatinteraction with beacons is acceptable, control may proceed immediatelyto a “User Approved?” block 256 and, instead of detecting beacons,process 250 detects an explicit signal from the user that beaconinteraction should be initiated. During processing associated with block254, shopper 130 has come within range of one or more of beacons151-156, which in this example are B_1 151. It should be noted that morethan one beacon may be detected at a particular time and that, if so,process 250 only illustrates the beacons being processing one at a timealthough in an alternative processing scenario multiple beans may beprocessed concurrently.

During processing associated with “User Approved?” block 256, adetermination is made as to whether or not B_1 151 is associated withany particular currently active session on smartphone 122. In addition,a user such as shopper 130 may initiate an interaction, or indicate adesire not to interact, with a detected beacon that has not previouslybeen encountered via, in this example, smartphone 122 (FIGS. 1 and 2).For example, if B_1 151 is being encountered for the first time, shopper130 may use a gesture, an entry on screen 124 (FIG. 1), a shake or anyother manner in which a user may provide input to smartphone 122 toeither initiate or decline the interaction. If shopper 130 has indicatedacceptance, either previously or at this point, control proceeds to an“Observe Broadcasts” block 258. During processing associated with block258, transmissions from B_1 151 are received and, if necessary, storedfir further processing as described below.

During processing associated with an “Existing Session?” block 260, adetermination is made as to whether or not B-1 151 is associated with anexisting session. Such as determination is made by AMM 206 (FIG. 3) andSMM 208 (FIG. 3) with reference to beacon data 214 (FIG. 3) and sessiondata 216 (FIG. 3). If there is an existing session, control proceeds toa “Notify Application (App.)” block 262, the transmission is forwardedto the application corresponding to the existing session and controlreturns to block 258. If, during processing associated with block 260, adetermination is made that the broadcast observed during processingassociated with block 258 is not associated with an existing session,control proceeds to a “Pre-Approved (Pre-Appr.) Session?” block 264.During processing associated with block 264, a determination is made asto whether or not B_1 151 has been “pre-approved” for a session. Inother words, a user has already specified that a beacon is approved andthe constraints associated with the beacon have already been specified,typically because of permissions of the application to which the sessionwill be associated. Application permissions may have been createdexplicitly in a permissions or settings page, or as part of a previoussession initiation with the same or another beacon where the usergranted future permissions while creating a session. If a determinationis made that a session is not pre-approved, control proceeds to an“Associated With App.?” block 266.

During processing associated with block 266, a determination is made asto whether or not the pre-approved session is already associated with anapplication, if not, control proceeds to an “Open & Filter Catalog”block 268. During processing associated with block 268, a relevantapplication catalog is accessed and the available applications arefiltered to present shopper 130 with the selection form among theapplications that are relevant to B_1 151. During processing associatedwith an “App. Downloaded?” block 270, a determination is made as towhether or not the application or applications a user has selectedduring processing associated with block 268 have been able to bedownloaded. Upon download of an application, relevant beacon informationis passed from the time the session was initiated, along with a note oninitiation time. This may differ from the current beacon broadcastinformation as downloading an application may take some time. Theapplication may choose to use this information how it desires, eitherpresenting information relevant to the user's original location whenthey initiated the session or the new location as new beacon informationis sent to the application or both.

If one or more apps have been downloaded, or if during processingassociated with block 266, a determination is made that the session isalready associated with an application, control proceeds to a “DetermineConstraints” block 272 during with shopper 130 is able to define anyconstraints to be placed upon B_1 151 and the associated session andapplication or applications. Constrains may include, but are not limitedto, items such as time constraints, location constraints and applicationspecific constraints corresponding to an application associated withbeacon B_1 151.

Constraints may come from either B_1 151 or from the application orapplications selected and downloaded during processing associated withblock 268 or the application identified during processing associatedwith block 266. For instance, an application may declaratively describe,a specific type of session configuration. The application may also dothis in combination with B_1 151. For instance. B_1 151 mayautomatically be associated with a session of type A. A beacon servermay be used to match a beacon to a requested session type, or theapplication may be invoked programmatically and asked for details onsession constraints. The system may also remember settings from the lastsession associated with the application to determine constraints, and inthe absence of specification from any of these means may present a userinterface for shopper 130 to create constraints (which may then beautomatically remembered for future sessions). In the case of multipleapps being associated with the beacon the system may find differentconstraints for each applications.

During processing associated with a “Prompt User” block 274, shopper 130is given another opportunity to accept the session and the constraintsdefined during processing associated with block 272. Shopper 138 may beallowed to modify the constraints requested by an application in thisblock. For instance, the application may request a location basedsession that terminates when shopper 130 is no longer in proximity withbeacons associated with the session. Shopper 130 may add as furtherconstraint that the session will terminate in 15 minutes. Each sessionassociated with an application may be accepted separately or allavailable sessions may be accepted at once. When multiple applicationsare found, a condensed summary (such as a fliptych, stack of cards,accordion, or other collapsible control) may be presented to shopper 130with options to start sessions with any number of applications. Theclaimed subject matter may enable users to view the session requestsfrom multiple applications and may allow multiple selections to startmultiple sessions in one action. The confirmation or acceptance of thesession may be indicated with, for example, a gesture, an on-screen tap,touch or swipe motion.

During processing associated with a “Session Accepted?” block 276, adetermination is made as to whether or not shopper 130 has accepted thesession and constraints during processing associated with block 274. Ifso, or if during processing associated with block 264, a determinationwas made that the session was pre-approved, control proceeds to a“Create Session(s)” block 278, during which one or more sessions arecreated. Creating a session involves creating a record in smartphone 122recording the session constraints, associated application, start time,location and other metadata about the session.

Several types of sessions may be created. For example, for merchandisebeacons, shopper 130 may only want to be notified while they are near acorresponding location. In the case of an event beacon, a user may wantto get continuously updated for a beacon giving updates from an event(even though the user may be outside of the specified location).Different settings could be saved as different gestures the user canperform when opening an app. This way be can more easily change thesettings without having to change anything on a settings page.Alternatively the user can group the different settings into only twodifferent groups (more notifications/fewer notifications), which theuser can specify. This way the user only needs to remember two differentgestures to set his settings (i.e. tap versus swipe).

In the case of location based sessions, as long as a user remains in thepresence of some beacons associated with a corresponding application,the corresponding session continues to forward notifications. When thedevice recognizes the user is no longer in proximity with a beacon for acertain amount of time beyond a configurable threshold, the session maybe ended with the user receiving no more notifications from theapplication. A configurable threshold (see 220, FIG. 3) based upon suchmeasurable criterion as radio interference or incomplete coverage in anarea may also temporarily disrupt connections. The disclosed technologymay offer benefits beyond location and event based sessions whenmodifications are made to beacons and applications to work with thistechnology. In addition, location based sessions may be implementedindependent of the other aspects of the disclosed technology without anymodification to current beacons or applications.

Once the session has been created during processing associated withblock 278 or preapproved during processing associated with block 264,control proceeds to a Transition Point A, which is described in moredetail below in conjunction with FIG. 5. Finally, if a session is notaccepted during processing, associated with block 276, if adetermination is made that an appropriate application cannot bedownloaded during processing associated with block 270 or interactionwith the beacon detected during processing associated with block 254 isdeclined during, processing associated with block 256, control proceedsto an “End Initiate Session” block 279 during which process 250 iscomplete.

FIG. 5 is a flowchart of one example of a Monitor Beacons process 300that may implement aspects of the claimed subject matter. Like process250 (FIG. 4), in this example, logic associated with process 300 isstored on CRSM 172 (FIG. 2) and executed on one or more processors notshown) of CPU 162 (FIG. 2) and smartphone 122 (FIGS. 1 and 2) inconjunction with BMM 176 (FIGS. 2 and 3). The following description usesshopper 130 (FIG. 1) and beacons 151-156 (FIG. 1) as examples of how theclaimed subject matter works and may be implemented.

Process 300 starts in a “Begin Monitor Beacons” block 302 and proceedsimmediately to a “Start Monitor” block 304. Process 300 is typicallystarted via Transition Point A (FIG. 4) in response to a session beinginitiated as described above in conjunction with process 250 (FIG. 4),either by a process (not shown) that continuously monitors for beaconswithin range or by a user who explicitly initiates process 250.

During processing associated with an “Observe Broadcasts” block 306,smartphone 122 monitors radio frequencies associated with beacons suchas beacons 151-156. In response to a transmission being detected,control proceeds to an “Active Session?” block 308, during which process300 makes a determination is made as to whether or not the signalreceived during processing associated with block 306 is associated withan active session. This determination is made by correlating the beaconthat initiated the signal (see 214, FIG. 3) with a session (see 216,FIG. 3) on smartphone 122 and then, if such a session exists,determining whether or not the session is active. If process 300determines that the beacon associated with the beacon observed duringprocessing associated with block 306 is not part of an active session,control proceeds to an “Ignore Beacon” block 310. During processingassociated with block 310, the transmission is simply ignored andcontrol returns to block 306 and process 300 continues to monitor beacontransmissions.

If, during processing associated, with block 308, a determination ismade that the signal received, during processing associated with block306 is associated with an active session, control proceeds to“Constraints (Con.) Satisfied?” block 312. During processing associatedwith block 312, a determination is made as to whether or not thetransmission meets criterion corresponding to the constraints placedupon the corresponding session (see 272, FIG. 4). If so, controlproceeds to a “Notify App.” block 314 during, which the broadcastreceived during processing associated with block 306 is forwarded to theapplication associated with the active session determined duringprocessing associated with block 308.

If, during processing associated with block 312, a determination is madethat the constraints are not satisfied, control proceeds to a “SessionStill Valid?” block 316. During processing associated with block 316, adetermination is made as to whether or not the corresponding sessionshould be maintained or terminated. For example, a constraint mayspecify that only certain types of broadcasts are forwarded and thatafter a certain date no broadcasts are permitted. In that case, if anon-permitted type of broadcast is received prior to the terminationdate, the broadcast is not forwarded but the session is not terminated.If the session is still valid, control proceeds to Ignore Beacon 310 andprocessing continues as described above.

If during processing associated with block 316, a determination is madethat the session is no longer valid, control proceeds to a “TerminateSession” block 318 during which the session identified during processingassociated with block 308 is terminated. In addition, any applicationsassociated with a particular session would typically be terminated aswell. Control then proceeds to an “Any Session Valid?” block 320. Duringprocessing associated with block 320, a determination is made as towhether or not there are still any sessions that are active. If so,control returns to block 306, broadcasts are monitored and processingcontinues as described above. If not, control proceeds to an “EndMonitor Beacons” block 329 and process 300 is complete.

FIG. 6 is an illustration of a screen shot 350 on display 124 (FIG. 1)of smartphone 122 (FIGS. 1 and 2) generated in accordance with theclaimed subject matter. Screen shot 350 is showing information in theform of as message_1 352. In addition to display 124, smartphone 122includes a microphone 126 (FIG. 1) and a camera (FIG. 1) 128. Bothmicrophone 126 and camera 128 provide a user the means to interact withsmartphone 122. For example, microphone 126 may detect voice commandsand camera 128 may detect gesture-based commands.

In this example, screen shot 350 and message_1 380 are generated by GUI210 (FIG. 3) of BMM 176 (FIGS. 2 and 3). Message₁₃ 1 352 providesinformation about a conference, specifically “Conference World, July25-28, Orlando, Fla.” Additional information, i.e., “Get More InfoThrough July 28^(th),” notifies the user that an application associatedwith this conference includes the constraint that the application, andthe session associated with the application, will have the constraintthat information will not be provided after July 28^(th),” A checkbox354 enables the user to specify, that the corresponding applicationshould be “pre-approved” by specifying “Don't ask again for this app.Just accept it next time.” In this example, the user may touch display124 to check box 354 and indicate the acceptance of the correspondingconstraints by either a verbal or gesture-based command. Although notillustrated, a user may also have pre-designated inputs for frequentlyused commands. For example, a specific gesture or shaking or telephone124 may indicate the user desires to “mute” a particular application ofbeacon, either by temporarily silencing notifications or permanentlysilencing the application or beacon by terminating a session.

FIG. 7 is another illustration of a screen shot 360 generated inaccordance with the claimed subject matter. Like FIG. 6, FIG. 7 includessmartphone 122 (FIGS. 1 and 2), display 124 (FIG. 1), microphone 126(FIG. 1) and camera 128 (FIG. 1) and screen shot 360 and message_2 362are generated by GUI 210 (FIG. 3 of BMM 176 (FIGS. 2 and 3). Message_2362 includes notifications from a beacon that is associated with anactive Session. In this example, message_1 362, which might beassociated with a pizzeria. (not shown), indicates some currentspecials, specifically “Notifications: •PIZZA 50% off; •Cheese on sale;•Check out our olives; • . . . ” In addition, a “Shake to Mute” button364, enables a user to turn off the notifications associated with thisparticular beacon and session.

FIG. 8 is another illustration of a third screen shot 384) generated inaccordance with the claimed subject matter. Like FIGS. 6 and 7, FIG. 8includes smartphone 122 (FIGS. 1 and 2), display 124 (FIG. 1),microphone 126 (FIG. 1) and camera 128 (FIG. 1) and screen shot 360 andmessage_2 362 are generated by GUI 210 (FIG. 3) of BMM 176 (FIGS. 2 and3).

In this example, shopper 130 (FIG. 1) has opened an app store (notshown) directly and BMM 176 checks for nearby beacons and then showsapplications which can handle those beacons. This is a slightlydifferent process than prompting shopper 130 to download the app when inthe presence of a beacon and is triggered by the user opening an appstore or catalog. When searching for apps, a visual indicator may beshown of the app can handle a nearby beacon.

Message_3 382 enables a user to select applications associated withthree different retail stores for three detected beacons. In thisexample, a user is prompted to “Select APP:” associated with a “RetailStore X,” a “Retail Store Y” and a “Retail Store Z.” A button 384enables acceptance of an application associated with Retail Store 1, abutton 386 with an application associated with Retail Store Y and abutton 388 with an application associated with Retail Store Z. A linealong the bottom of message_1 382 indicates that “Beacons Nearby” areindicated by a symbol 390, as indicated in buttons 384 and 388.

Some features provided by the claimed technology include, but are notlimited to, session-based interactions that span multiple beacons,gesture-based session initiation and termination, privacy informationoverload noise protection through sessions, location-based, sessions andtime-based sessions.

The disclosed technology provides as novel and much improved userexperience around beacons, puts more control in the hands of the userover which notifications they receive and greatly reduces unwantednotifications and notification overload. In addition, the technology hasan added advantage of improving battery life and data usage by reducingthe times when a device needs to interact with beacons and times whenapplication code related to beacons is called.

The disclosed techniques also improve on the adoption of beacontechnology. Current beacon approaches discourage widespread use ofbeacon enabled applications, or “apps,” due to potential notificationoverload, requiring users to be selective with the apps allowed tointeract with beacons and the corresponding notifications. Unlike theclaimed subject matter, current approaches also typically require theadvance downloading of an application to interact with beacons.

The terminology used herein is for the purpose of describing particularembodiments only and is not. intended to be limiting of the invention.As used herein, the singular forms “a”, “an” and “the” are intended toinclude the plural forms as well, unless the context clearly indicatesotherwise. It will be further understood that the terms “comprises”and/or “comprising,” when used in this specification, specify thepresence of stated features, integers., steps, operations elements,and/or components, but do not preclude the presence or addition of oneor more other features, integers, steps, operations, elements,components, and/or groups thereof.

The corresponding structures, materials, acts, and equivalents of allmeans or step plus function elements in the claims below are intended toinclude any structure, material, or act for performing the function incombination with other claimed elements as specifically claimed. Thedescription of the present invention has been presented for purposes ofillustration and description, but is not intended to be exhaustive orlimited to the invention in the form disclosed. Many modifications andvariations will be apparent to those of ordinary skill in the in withoutdeparting from the scope and spirit of the invention. The embodiment waschosen and described, in order to best explain the principles of theinvention and the practical application, and to enable others ofordinary skill in the art to understand the invention for variousembodiments with various modifications as are suited to the particularuse contemplated.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods and computer program products according to variousembodiments of the present invention. In this regard, each block, in theflowchart or block diagrams may represent a module, segment, or portion.of code, which comprises one or more executable instructions forimplementing the specified logical function(s). It should also be notedthat, in some alternative implementations, the functions noted in theblock may occur out of the order noted in the figures. For example, twoblocks shown in succession may, in fact, be executed substantiallyconcurrently, or the blocks may sometimes be executed in the reverseorder, depending upon the functionality involved. It will also be notedthat each block, of the block diagrams and/or flowchart illustration,and combinations of blocks in the block diagrams and/or flowchartillustration, can be implemented by special purpose hardware-basedsystems that perform the specified functions or acts, or combinations ofspecial purpose hardware and computer instructions.

1. A method for controlling message delivery corresponding to a nearfield communication (NFC) device, comprising: establishing, on a mobilecomputing device of a user, a rule-based session corresponding to a NFCdevice; detecting, by the mobile computing device, that the NFC deviceis approved by the user; executing, on the mobile computing device inresponse to the detecting, an application, corresponding to the NECdevice, in conjunction with the session; and responsive to detecting acondition meeting a criterion corresponding, to the rule-based session,limiting, by the mobile computing device, execution of the applicationon the mobile computing device in conformity with the criterion.
 2. Themethod of claim 1, further comprising: determining that a second NFCdevice is not associated with a second session; and limitingcommunication with the second NFC device in response to the determining.3. The method of claim 1, wherein the limiting execution comprisespreventing the application from transmitting a notification to the user.4. The method of claim 1, wherein the limiting of execution comprisespreventing the mobile computing device from displaying a messagecorresponding to the NFC device.
 5. The method of claim 1, furthercomprising adjusting the criterion based upon interactions by a user ofthe mobile computing device.
 8. The method of claim 1, the criterionselected from a list, the list consisting of: a time constraint; alocation constraint; and an application specific constraintcorresponding to an application associated with the NFC device.
 7. Themethod of claim 1, wherein the NFC device is a beacon.
 8. The method ofclaim 1, further comprising: determining that the application is notloaded on the mobile computing device; and in response to thedetermining that the application is not loaded, downloading theapplication onto the mobile computing device.
 9. An apparatus forcontrolling message delivery corresponding to a near field communication(NFC) device, comprising: a processor; a computer-readable storagemedium coupled to the processor; and instructions, stored on thecomputer-readable storage medium and executed on the processor, toperform a method, the method comprising: establishing, on a mobilecomputing device of a user, a rule-based session corresponding to a NFCdevice; detecting, by the mobile computing device, that the NFC deviceis approved by the user; executing, on the mobile computing device inresponse to the detecting, an application, corresponding to the NFCdevice, in conjunction with the session; and responsive to detecting acondition meeting a criterion corresponding to the rule-based session,limiting by the mobile computing device, execution of the application onthe mobile computing device in conformity with the criterion.
 10. Theapparatus of claim 9, the method further comprising: determining that asecond NFC device is not associated with a second session; and limitingcommunication with the second NFC device in response to the determining.11. The apparatus of claim 9, wherein the limiting execution comprisespreventing the application from transmitting a notification to the user.12. The apparatus of claim 9, wherein the limiting of executioncomprises preventing the mobile computing device from displaying amessage corresponding to the NFC device.
 13. The apparatus of claim 9,further comprising adjusting the criterion based upon interactions by auser of the mobile computing device.
 14. The apparatus of claim 9,wherein the NFC device is a beacon.
 15. A computer programming productfor controlling message delivery corresponding to a near fieldcommunication (NFC) device, comprising a non-transitorycomputer-readable storage medium having program code embodied therewith,the program code executable by a plurality of processors to perform amethod comprising: establishing, on a mobile computing device of a user,a rule-based session corresponding to a NFC device; detecting, by themobile computing device, that the NFC device is approved by the user;executing, on the mobile computing device in response to the detecting,an application, corresponding to the NFC device, in conjunction with thesession; and responsive to detecting a condition meeting a criterioncorresponding to the rule-based session, limiting, by the mobilecomputing device, execution of the application on the mobile computingdevice in conformity with the criterion.
 16. The computer programmingproduct of claim 15, the method further comprising: determining that asecond NFC device is not associated with a second session; and limitingcommunication with the second NFC device in response to the determining.17. The computer programming product of claim 15, wherein the limitingexecution comprises preventing the application from transmitting anotification to the user.
 18. The computer programming product of claim15, wherein the limiting of execution comprises preventing the mobilecomputing device from displaying a message corresponding to the NFCdevice.
 19. The computer programming product of claim 15, furthercomprising adjusting the criterion based upon interactions by a user ofthe mobile computing device.
 20. The computer programming product ofclaim 15, wherein the NFC device is a beacon.